home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Netware Super Library
/
Netware Super Library.iso
/
nov_info
/
fyi8
/
080313.dos
< prev
next >
Wrap
Text File
|
1990-08-03
|
10KB
|
184 lines
Number: F4TH071990U164
Subject: WAN Scenario Message Thread
Date: August 1, 1990
- - - - - - - - - - - - - - - - - - - - - - -
GENERAL
INFORMATION: This message is intended to start a discussion on this
subject.
We have the following situation:
DOWNTOWN MIDTOWN
VERTICAL VERTICAL
BACKRING /----------X.25 London BACKRING
/
+------+ / X.25 Chicago +------+
39th fl--| | X.25----------/ \ | | subnet1
| | \ | |--21st fl--|
38th fl--| | ---------X.25 | | subnet2
| | / | |--7th fl
33rd fl--| | X.25 Los Angeles | |
| | | |
| |--VITALINK====via T1===VITALINK--| |
+------+ +------+
The scenario is as follows:
There are existing X.25 routers in place, connecting several
different areas on the network with a variety of different
locations worldwide via a private X.25 network. Currently,
this is also how DOWNTOWN speaks to MIDTOWN.
To improve performance and allow additional nonNetWare
traffic to cross between DOWNTOWN and MIDTOWN, they are
installing a Vitalink bridge with a full T1 circuit to unite
the two vertical riser back-rings together. They understand
that they need to change some network addresses to make the
scheme work. Now, both back-rings will be address BBBBBBBB
(this is actually being piloted tomorrow).
The problem that's being anticipated is this:
What happens if the T1 link or one of the bridges go down?
We suddenly have a misconfigured network. Two different,
not-connected-together networks are being called BBBBBBBB.
More than that, if any one of their X.25 bridges just happen
to connect to the same remote city, we won't know we have a
problem, exactly. We would not anticipate that we would
have traffic jumping DOWNTOWN to Chicago to MIDTOWN (if
that would work, we would tell them to use the X.25 routing
as a backup by maintaining their current configuration in
parallel) since the destination network for a resource on
the other side of the bridge is BBBBBBBB. The shortest
route to that network would continue to be the same router,
but the destination node would be inaccessible since it's on
the wrong side of the bridge that's out.
The issue will go away for this site when they add a third
downtown site to the Vitalink+T1 network -- the spanning
tree algorithm will deal with links that are unavailable.
Even without that, the reliability of the Vitalink could be
beefed up by dedicating a second, smaller circuit to back it
up.
That leaves them with the concern of what happens if the
bridge box itself fails.
We suggested that they consider using two separate bridge
boxes. The concern there was that the Vitalink adds a lot
of value in terms of minimizing broadcast chatter if one
bridge manages both parallel links.
One group discussing this suggested we eliminate the
multiple routes. That's good for reliability (if the link
fails, we just lose the service, not the network integrity)
but bad from a services level. It means that if the link
fails (and we can tell you as NY Telephone digital customers
that it will - several times per year), half the network
losed connection to Chicago.
Ideally, they are looking for a solution that:
- Allows them to maintain their multiple connections via X.25
- Withstands loss of the link without causing the network to
fail in a mysterious manner (i.e, No Response from given
server)
- Is less expensive than point to point lines all over the
place (they own GEONET - a worldwide X.25 private data
network)
Well, it's a challenge. Let us know your thoughts, random
or sequential, on this matter.
----------------------------------------------------------------------------
I have two suggestions:
1. This may sound a little hairbrained but:
On the Vitalink connection, extend the network #BBBBBBBB off
the Vitalink from the downtown backbone with an external
bridge (or internal). So what you would have is a MAU with
two connections; one from the Vitalink and the other from
the bridge to downtown ring call it network number "BACB".
That way you would have the highspeed preferred route over
the Vitalink and safety from network failure it if goes
down. See below.
DOWNTOWN MIDTOWN
VERTICAL VERTICAL
BACKRING /----------X.25 London BACKRING
/
+------+ / X.25 Chicago +------+
39th fl--| | X.25----------/ \ | | subnet1
| | \ | |--21st fl--|
38th fl--| | ---------X.25 | | subnet2
| | / | |--7th fl
33rd fl--| | X.25 Los Angeles | |
| | | |
| |-- FS/ ----- VITALINK==VITALINK--| |
+------+ Bridge +------+
#BACB #BBBBBBBB
You are also protected this way from failure of any route.
The other alternative, would be set up the X.25 hardware but
NOT make the network call connection EXCEPT in case of
failure of the Vitalink. Your customer could be back up
with within minutes of the failure over the X.25 network.
You could setup circuits which could be initiated from
either side (i.e. place a call answer on both sides which
would wait for the call originate from the other side).
We like the first solution better because there is no chance
of failure and we believe that the end user would see no
degradation of the Vitalink connection because our internal
bridge has to be faster than T1.
Good luck and let us know what you decide.
------------------------------------------------------------------------------
Pretty good...but they do want some nonNetWare traffic to
cross from backbone to backbone eventually (primarily 3174's
talking to 3725's and the like).
But maybe using NetWare routers w/o source routing in
parallel to IBM source routing bridges. It's got lots of
delay but it would probably be reliable.
The problem with the X.25 scenario is that if they have
both sides configured as BBBBBBBB, when the link is broken,
even if they have another route, NetWare will never use it.
It will still see all kinds of activity on a network called
BBBBBBBB that will always be fewer ticks away than the one
across GEONET. In fact, you would probably be able to see
the SAP of all the servers on the other side, but you could
never get to them. The only way to make that work is to
temporarily renumber one side to something other than
BBBBBBBB.
------------------------------------------------------------------------------
One possibility that they are going to look into with
Vitalink is a BROUTER - a combination bridge/router that
can route the IPX traffic and bridge the rest.
That would solve the problem immediately.
------------------------------------------------------------------------------
We think the reason for putting the Vitalink between the
two offices in the first place is so that protocols other
than IPX/SPX will travel between the two rings. Putting the
Novell router in series with the Vitalink sort of "filters"
out the other protocols before they get to the other ring.
We think a CYSCO router between the two rings will allow
them to route all sorts of traffic through the link and
still keep the LAN addresses unique.